COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	@make(letterhead,Phone"497-4430",Who"John McCarthy",Logo old, Department CSD)
C00012 ENDMK
C⊗;
@make(letterhead,Phone"497-4430",Who"John McCarthy",Logo old, Department CSD)
@begin(address)
Professor Herbert Simon
Department of Computer Science
Carnegie-Mellon University
Pittsburgh, Pennsylvania  l5213
@end(address)
@greeting(Dear Herb:)
@begin(body)
	Thanks for your "Search and Reasoning in Problem Solving"; it
was very readable, so I read it.

	I agree with your conclusion at the end that thinking should
not be equated with formal logic.  I don't think I ever supposed
otherwise, though my opinion has fluctuated on the extent to which
AI programs should be primarily logical reasoners.   Here are some
comments:
@begin(enumerate)
Modal logic is not non-monotonic, i.e., it's monotonic.  Any conclusion
@i(p) that follows from a collection  @i(A) of assertions will also follow from
any more inclusive collection  @i(B) of assertions.   I prefer not to call
the non-monotonic systems logics at all and refer to non-monotonic reasoning
in my paper.  However, this is a minor point.  It doesn't seem to me that
your error in this matter affects the main line of reasoning of the
paper, because your examples of non-monotonic reasoning are proper, and
you give no examples of modal logic.

I am very doubtful that UNDERSTAND, as you describe it, could solve
missionaries-and-cannibals.  Suppose that the reference to a boat is
in a sentence, "There is a boat that can hold two people at a time".
This is syntactically isomorphic to the sentence, "There is a bridge
that can hold two people at a time", and yet they lead to quite different
solutions to the problem.  It seems to me that trying to get by
with mere syntax can lead to fooling oneself into making a system
that can solve only problems very similar to the ones with which
it was debugged.

@begin(multiple)
My major reason for proposing a declarative representation
of common sense knowledge in 1958 (The paper appeared two years
after the conference.) was to achieve generality.  The knowledge
about boats, for example, should be usable for any problem about
boats that might come up.  This includes problems that infer     
the existence or non-existence of a boat as well as problems that
may involve using a boat that may or may not be usable or may or may
not require fixing.  That project, which might today be called
making a common sense data base, was unrealizable at that time, and
still hasn't been realized.  However, the development of formal
methods of non-monotonic reasoning brings it closer to realizability.

The modal logics mentioned in "Some philosophical ..." had a different
purpose than non-monotonic reasoning; and I didn't develop any formal
methods of non-monotonic reasoning until the middle 70s, which
coincided with the M.I.T. work on non-monotonic logic, although the
two were independently conceived.  Hayes and I discussed using
Prior's tense logics and various logics of belief based on classical
modal logic.  For expressing facts about modalities like knowledge,
belief and futurity, modal logics are one candidate.  However, the
modal logic can always be avoided by ireifying the objects of the
modal operator as I do in my paper, "First order theories of individual
concepts and propositions".  My current slogan is "Modality si!  Modal
logic no!"
@end(multiple)

@begin(multiple)
Consider what the common sense data base should know about using
boats.  Among other things, it should know that a leak or lack of
oars may prevent the use of a boat.  However, putting the requirement
that there be oars as an explicit precondition for the use of
a boat will prevent a problem solver that relies on
this data base for information about boats
from solving m-and-c, because nothing is
said about oars in the statement of the problem.
Perhaps the generality issue is clearer when we consider facts
about an object that permit a solution of a problem in a way
that does not involve a customary use of the object.  For example,
we may sell the boat, hide in it, set it adrift or burn it for firewood.
Conversely, it may constrain the solution of a problem, because it
is to big to move to a hiding place or portage to the next place
where it might be used.

The advantages of declarative representations in general, and logic
in particular, would be more obvious if we had programs that needed
to take into account facts about boats in all the above ways.
@end(multiple)

@begin(multiple)
I don't see that the equations of physics are anything other
than logical sentences once the quantifiers have been put in.
Remember that these equations are ordinarily surrounded by prose
describing what the symbols in the equations stand for.  If
we must formalize this prose, so that the equations can be
included in our common sense data base, then mathematical logic
seems like the obvious candidate.

However, whenever we are prepared to provide for the computer
a method of solving a particular class of problems, logic will
usually not be the optimal way of representing the method.
A physicist can solve problems from first principles and uses
first principles to devise methods, but uses "compiled" methods
for routine problems.
@end(multiple)

The STRIPS-like systems are useful but turned out to be too
special for representing general information and have been
abandoned by their original authors for that reason.

@begin(multiple)
Non-monotonic reasoning has nothing intrinsically to do with
change in time, and therefore there is no occasion for
this literature to take into account the fact that physical
scientists have been using state spaces.  It is more the
observation that Ockham's razor is used in common sense reasoning
as well as in formal philosophy together with the requirement
that the non-monotonic reasoning be formalized in some way.
What's new are the formalizations.

	I'm preparing a paper that includes formalizations of
facts about moving blocks.  It includes proposals for including
facts that a block may be too heavy to move but allowing jumping
to the conclusion that a block is movable when information to
the contrary isn't present.  Perhaps we can discuss these issues
more at AAAI.
@end(multiple)
@end(enumerate)
@end(body)
Best regards,




John McCarthy
Professor of Computer Science